Conversation
|
Another potential candidate for friendlyifying: (instantiate motor, disconnect motor, access attribute... BAM! error.) |
| raise ValueError("The given speed value was out of range") from driver_error | ||
| else: | ||
| raise ValueError("The given speed value was out of range. Max speed: +/-" + str(max_speed)) from driver_error | ||
| raise ValueError("One or more arguments were out of range or invalid") from driver_error |
There was a problem hiding this comment.
I am still not convinced a value error is more friendly than OSError to be fair. OSError is the thing that happens in the background, why do we want to 'protect' the user from this?
May be it would be better to at least re-raise the original (OSError) exception instead of generic 'One or more arguments were out of range or invalid' for unsupported attributes?
There was a problem hiding this comment.
I mean, what would make the debugging easier?
There was a problem hiding this comment.
I am still not convinced a value error is more friendly than OSError to be fair. OSError is the thing that happens in the background, why do we want to 'protect' the user from this?
That the nice Python functions happen to be calling an operating system routine is an implementation detail. As far as the user is concerned, they called the function and provided an argument that was out-of-range; a ValueError is the Python concept that describes such an issue, and the message explains what went wrong. If the user is interested in the OSError, they can see it as the __cause__ of the ValueError (hence raise ... from).
For most casual programmers, the message OSError: [Errno 22] Invalid argument will be confusing -- it isn't natural to expect an OSError for this sort of scenario, and the message certainly isn't clear. Unless I'm directly consuming OS functions, I would generally expect an OSError to indicate an issue with the implementation of a library, not my own mistake.
May be it would be better to at least re-raise the original (OSError) exception instead of generic 'One or more arguments were out of range or invalid' for unsupported attributes?
See above; the inner exception is available, just within the user-friendly error that we throw.
There was a problem hiding this comment.
I mean, what would make the debugging easier?
The error tells you exactly what you did wrong; no question is left as to what was going on when the error occurred or what caused it.
There was a problem hiding this comment.
what would make the debugging easier for me if the exception text always included
- the name of the attribute we are trying to set
- the value we are trying to set it to
- the min/max or acceptable inputs for that attribute
that would be very useful
Fixes #331
It would be nice if we were able to adapt the message when you attempt to run for distance with a negative sign, but commands are read-only and I didn't see an easy way to pipe that through. Any suggestions for other properties?